在之前的文章中提到過，在 Planning 中進行 Refine 容易造成開會時間冗長，造成討論缺乏效率的問題。那麼，把 Refine 從 Planning 中獨立出來，難道就不會變成一個冗長的 Refinement 嗎？ 本篇就來聊聊，高效率 Refinement 會議的具體實踐方式。
回顧我們的「規畫系統」圖， Refinement 是其中的一個子系統：

Refinement 系統的產出為具有以下特性的 User Story：

• 內含經過 PO，設計師以及開發團隊確認過的 UI/UX 規格
• 經過開發團隊確認的驗收條件 (Accept Criteria)
• 根據工程實務，將 User Story 拆分成細顆粒度的執行項目 ( Tasks )
• 針對執行項目進行點數估計

為了優化「效率」，我將 Refinement 拆成「線上」(online) 與「線下」(offline)：

線上 Refinement

時間：1 小時 (務必堅守)

流程：

• PO 說明對用戶的價值，驗証目標 ( 5 - 10 mins)
• 設計師解釋設計，與使用者流程 (10 - 15 mins)
• RD (Backend, Mobile, Web, Native) 與 QA 依據領域專業，分組針對 User Story，UI/UX 進行審閱，並整理問題 ( 10 - 15 mins)
• PO 與設計師回答開發端的提問；可以立即做出判斷的回答，可以直接決斷；也常發生開發團隊提出了很棒的建設性問題，PO/設計師需要時間思考，就回到線下進行。( 10 - 15 mins)
• 根據 User Story 複雜度的不同，若仍有充足的時間進行下一個 Refinement，剛重覆上述動作，直到會議時間結束。

線下 Refinement

時間：無限制，由團隊成員自行規畫時間進行，所需時間計入工作時間

流程：

• Scrum Master 與團隊約定最晚應完成時間。
• PO 與設計師針對線上會議未回答的問題進行思考與補強。
• 在線上 Refinement 中已取得的資訊，讓團隊回到各自舒適的場域進行思考。並根據領域專業，分別切分成細顆粒的執行項目 (Tasks)。例如：UI 設計，商業邏輯設計，API 設計，基礎架構設計…等。
• 對執行項目進行估點。(估點方式的探討，留待下一篇文章細聊)

透過每個流程的時間限制，讓團隊在集體會議中可以聚焦討論。而線下活動則是讓開發團隊可以在安靜的環境，並確保其心理安全 (規畫屬工作的一部分，計入工時) 的條件下，得到優質的 Refinement 結果。

Scrum 行事曆

至於， Refinement 會議的時間如何規畫，我用假想 Scrum 團隊的行事曆來作說明，請見下圖。

這個團隊的開發週期是 2 週，每個 Sprint 的第 1 天進行 Planning ，而可以拉進 Planning 的工作項目，是透過前兩週的 Refinement 得到。這裡可能會衍生的另一個疑問題，這樣做，團隊的前一個 Sprint 不就被打擾了嗎？ 這個問題，我留到介紹 Planning 的時候再釋疑。

下一篇文章，我會來補本篇留下的坑，介紹一種變型的估點實踐方法。明天見！